Five `>> $GITHUB_OUTPUT` redirects in this workflow were left unquoted, which
shellcheck flags as SC2086 and which master already cleared everywhere else
ahead of enabling the rule.

1. Keep the version bump at HEAD on release proposal branches by preventing license auto-commits there.
2. Keep scoped package identities slash-delimited so Windows sandbox setup patches their peers.
3. Regenerate license attribution when any source input changes instead of only on lock updates.

…range

`@aws-sdk/client-bedrock-runtime` forced `@smithy/node-http-handler` at `*`, so
every bedrock sandbox received the newest published handler regardless of the
`@smithy/*` generation it was built against. The 3.422.0 sandbox declares
`^2.1.5`, got a v4 handler, and that handler resolved its own `@smithy/core` v3
independently of the rest of the sandbox, so loading it threw `MODULE_NOT_FOUND`
on `@smithy/core/protocols`. Which majors collide depends on what the registry
published inside the install's `minimumReleaseAge` window, so the sandbox broke
on a day when nothing in the repository had changed.

A forced transitive now takes an explicit `version` first, then the range the
installed package declares for itself, and only then the latest-version pin.
Entries genuinely absent from their parent's manifest (`moleculer` → `bluebird`,
`@prisma/client` → `mongodb`) are unaffected. The sandbox assertion accepted any
`semver.validRange`, which `*` satisfies, and now requires the injected range to
be a subset of what the client itself declares.

Bun sets `npm_execpath` to its own executable rather than to a JavaScript entry
point, so the bootstrap ran `node <60 MB binary> install` and Node exited on a
bare `SyntaxError` while parsing it as CommonJS. The version check that reports
`Could not install Bun` never ran, leaving a parser error as the only output.
The branch is reached whenever the bootstrapped binary is missing, which is what
`bun install --ignore-scripts` leaves behind, so any Bun-launched script in that
state failed with an unrelated error.

Each vendored bundle contains code from several packages, but the plugin emitted
`modules[0].licenseText` — whichever package the bundler happened to order first.
That order follows the installer's `node_modules` layout, so replacing Yarn with
Bun reshuffled it and `@apm-js-collab/code-transformer` shipped Mozilla's
BSD-3-Clause text in place of its own Apache-2.0 license, while every other
package in the bundle went unattributed.

Each `LICENSE` now carries every bundled package's text, name-sorted so the
result no longer depends on the installer. A package that publishes no license
file falls back to a canonical template chosen by the SPDX id its manifest
declares, which is how `crypto-randomuuid` resolves, and an id with no template
fails the build instead of shipping a bundle with a missing license.

1. The lock walk followed only `dependencies` and `optionalDependencies`, so a
   production package's peers were treated as dev-only and went unattributed.
   `@datadog/openfeature-node-server` is an optional dependency whose peer
   `@openfeature/server-sdk` is satisfied by a range declared under
   `devDependencies`; `bun install --production` resolves it, so it and
   `@openfeature/core` ship inside the OCI package with no license row. A peer
   nobody installed has no lock entry and still drops out.
2. The generated CSV had moved to LF while `.github/vendored-dependencies.csv`
   stayed CRLF. The license workflow appends the second file to the first, so the
   result carried mixed endings, editors re-LF it on save, and the release tooling
   re-committed it on every run.

`bun audit --ignore <id>` accepts ids it never saw without complaining, so an
inline ignore list keeps suppressing an advisory long after the dependency was
patched and nothing reports that the entry is dead. Three of the five ignored
advisories were in that state: `form-data`, `path-to-regexp`, and `undici` each
had a patched release inside the range their parents already declare, so
re-resolving those three lock entries clears them and the ignores go away.

Accepted advisories now live in `.github/audit-allowlist.json`, one entry per
directory with a written reason, and the wrapper fails both on an advisory that
is not accepted and on an acceptance that no longer matches anything. The
threshold is per directory because `vendor` is bundled and shipped, so a moderate
advisory there reaches customers, while `--audit-level=high` had been filtering
it out.

The cassette reference told readers to run `PLUGINS=<integration> yarn services`
to install a missing version fixture. Yarn is no longer installed, so the command
fails outright; the fixture stays missing and the spec keeps reporting a broken
module. The guard test that keeps yarn out of the tree fails on the reference too.

…list

The generator fed `.github/vendored-dependencies.csv` through the same map as the
lockfile walk, so its rows were sorted in among the installed packages. Those two
rows attribute code copied into this repo — a regex from `is-git-url`, handler-path
logic from the AWS Lambda runtime interface client — not packages the artifact
resolves. Alphabetical placement asserts we ship an `is-git-url` that no lockfile
has ever contained, which is the opposite of what an attribution file is read for.
They now trail the sorted dependencies, the layout `dd-license-attribution` produced
by appending the file.

A name appearing in both lists would emit two rows for one component, and
`check_licenses.js` compares name sets, so nothing downstream would catch it. The
generator now fails instead.

Severity is ranked by index into a fixed list, and an unrecognized string yields
-1, which sorts below every configured threshold. A renamed or newly added bun
severity therefore skips every advisory carrying it and the job reports a clean
tree, which is the failure the wrapper exists to prevent rather than one it can
absorb quietly.

The workflow only watched lockfiles, so a PR could add or edit an entry in
`.github/audit-allowlist.json` — or change `scripts/audit.js` itself — and merge
without ever running the wrapper that checks every exemption still carries a
reason and is still reported. An exemption is only as good as the run that
re-checks it, so the policy and the enforcing script now trigger the workflow
alongside the lockfiles they gate.

Refs: #8386

The setup action hard-coded `bun@1.3.14` while `package.json` holds the pin that
`scripts/bun.js` enforces. Dependabot updates the devDependency without touching
the action, and nothing then runs the wrong Bun — `getBunBinary()` bootstraps the
pinned one locally — but every CI job pays for that bootstrap until someone
notices the two numbers drifted. Read the pin instead of restating it.

The spec assertion moves with it: it used to compare the two literals, and now
requires the action to carry no literal at all. The playwright Dockerfile pin
stays literal because its `FROM` line needs the image digest too.

Refs: #8386

The langchain entry pinned `@langchain/openai@0.0.34`'s copy of
`@langchain/core` through a Yarn-style selective key
(`@langchain/openai@0.0.34/@langchain/core`). Bun only honours a bare package
name: it copies the key into the manifest and never applies it. Verified against
the pinned Bun — a selective key leaves `@langchain/core` at 0.2.36 while an
equivalent top-level override moves it — so the line read as an enforced pin
while resolution was untouched, and the old spec asserted the dead key was
present rather than that it did anything.

1. Remove the override. 0.0.34's own declared range already lands inside
   `^0.2.0`, which is what the spec now asserts. A top-level override is not the
   fix: it is workspace-wide and would drag langgraph's `>=1.1.16` sandboxes down
   to the 0.2 line.
2. Reject any override key that is not a bare package name at generation time, so
   the next selective or nested override fails loudly instead of reading as
   enforced.

Refs: #8386

Mergegate failed with "CODEOWNERS missing" for `.github/audit-allowlist.json`,
the fourth such failure on this branch after `docs/bun.lock`,
`versions/bunfig.toml` and `vendor/bun.lock`. The main lint does run a codeowners
audit, but only over five globs — `**/*.spec.js`, `benchmark/sirun/**`,
`.agents/**`, `.claude/**` and `integration-tests/**` — so no local gate covered
the tree this branch keeps adding files to, and every gap had to be found by
pushing.

1. Default the whole `/.github/` tree to the platform team instead of listing
   `/.github/actions/` and `/.github/all-green/` one directory at a time. GitHub
   applies the last matching rule, so the per-product entries further down keep
   the workflows and directories they already claim. This closes 16 pre-existing
   gaps, among them the issue templates, `dependabot.yml`, and the audit,
   flakiness, platform and release-proposal workflows.
2. Add `.github/**` and `scripts/**` to `lint:codeowners:ci`, so the next
   unowned file fails locally instead of in mergegate.

Drive-by: move the `/docs/bun.lock` and `/vendor/bun.lock` rules out of the
middle of the workflow block, where they had nothing to do with their
neighbours, into the Language Platform section. Ownership is unchanged; no other
rule matches either path.

Refs: #8386

## Summary

- keep sparse CI and OCI installs complete
- restore fail-closed Bun lock traversal and exact attribution refresh
- remove redundant fallback branches exposed by current lint

## Why

Sparse jobs invoke the Node setup action, which reads package.json to select the pinned Bun version. The OCI build also needs trusted dependency lifecycle scripts while skipping only the package prepare hook.

The extracted lock reader had lost the previous parser validation and ancestor/workspace resolution, allowing malformed or incomplete locks to silently shrink license attribution. Single-version rows also retained stale registry metadata.

## Test plan

- npm run test:scripts
- npm run lint
- node scripts/generate-3rdparty-licenses.js --check
- changed-line c8 coverage for the affected scripts

## Summary

Refresh the root Bun lock after the eslint-plugin-unicorn bump. Classify Bun locks correctly in release changelogs. Narrow GitHub ownership and remove the obsolete consumer-install action.

## Why

The rebased tree failed every frozen install because master advanced a dependency without the PR's new lockfile. Master's release tooling also reintroduced Yarn-only assumptions, while recursive GitHub ownership claimed workflows that already have product owners.

## Test plan

Complete script suite, full repository lint, frozen Bun install, changed-line coverage, generated license check, and shell syntax checks.

## Summary

Fresh license regeneration and dependency audits now pass against the Bun
lockfiles.

## Why

The license workflow invoked the Bun lock parser without installing jsonc-parser.
New high-severity advisories also made the root and docs audits reject stale
lock resolutions.

## Test plan

- `bun install --frozen-lockfile --ignore-scripts` in root and docs
- `node scripts/audit.js . docs`
- `node scripts/generate-3rdparty-licenses.js`
- `npm run test:scripts`
- `npm run lint`

PR-URL: #8386

## Summary

Exact plugin pins and reviewed copyright attribution remain authoritative; audit and package-size jobs use current Bun behavior.

## Why

Flexible latest ranges let plugin sandboxes drift above the tested pin, registry author fields overwrite reviewed copyright, and stale workarounds obscure Bun 1.3.14 behavior.

Dependabot now supports bun.lock, so a scheduled wrapper duplicates upstream advisory monitoring.

## Test plan

- npm run test:scripts
- ./node_modules/.bin/mocha scripts/test/generate-3rdparty-licenses.spec.js packages/dd-trace/test/plugins/versions.spec.js
- PLUGINS=pino npm run test:plugins
- npm run lint
- actionlint .github/workflows/audit.yml .github/workflows/instrumentation.yml .github/workflows/project.yml
- coverage-diff.js HEAD

Dependabot supports Bun version updates but not security updates, so newly disclosed advisories do not change bun.lock or trigger a pull-request audit.

* test(plugins): remove obsolete Bun dependency workarounds

Bun 1.3.14 and the current isolated installer produce valid dependency graphs for these packages without the added direct dependencies and overrides.

* test(plugins): remove stale workaround assertions

`test:scripts` still asserted Knex, Limitd, and AI dependency accommodations after those configurations were removed, so the release-scripts job failed.

A second Bun invocation is unsafe when the generated workspace state from the first failure remains in place.\n\nAllow one second workflow attempt for transient runner failures, and start both from an empty root node_modules tree.

1. @vscode/sqlite3 can run before its package-local tar dependency is available under Bun isolated workspaces.
2. The Yarn-free test PATH also hid Node, so trusted dependencies with Node lifecycle scripts failed before assertions ran.

@confluentinc/kafka-javascript@1.10.0 has no Node 26 prebuild, and its fallback source build fails before instrumentation tests start. The shared action stays on Node latest by default while this job uses the newest runtime its plugin matrix supports.

Master updated @datadog/pprof without the Bun lock, so every frozen CI install rejected the rebased dependency tree.

The Confluent 1.0-1.3 line has no Node 24 prebuild, so the
upper-runtime install falls back to a broken source build.

Use the plugin matrix's existing Node 24 package floor while Node 18
retains >=1.0 coverage.

Dependabot does not create security PRs for Bun locks, so its PR audit is additive to the existing scheduled, manual, and path-triggered audit. Checked advisory acceptances now fail when their justification goes stale instead of silently suppressing a later reintroduction.

Source-archive prepare can run before dev dependencies exist, and isolated Bun installs hardlink cache files. Resolving the pinned binary and replacing patched files by inode prevents bootstrap failures and shared-cache mutation.

Bun defaults to 48 concurrent network requests, which caused unrelated plugin jobs to fail while extracting registry tarballs before tests started. Apply the established eight-request limit here and keep the reviewed single-attempt behavior.

Concurrent generated-workspace downloads intermittently hit Bun tarball extraction failures, so unrelated plugin jobs stop before tests.